Client server model

ABSTRACT

The invention addresses the problems of server overload by installing an integrity manager ( 32 ) which intercepts calls from the client ( 10 ) to the server ( 12 ) and delays them. In addition the Integrity manager ( 32 ) can be downloaded automatically when a server service is first invoked.

[0001] The invention relates to an improved client server model, inparticular a computer system comprising a server module and a clientmodule.

[0002] The client-server model of computing is used throughout thecomputing industry for accessing shared server side capabilities such asprint queues, network devices and directories.

[0003] To date the client-server model has been primarily used withinintranets and extranets in particular in between parties that are wellknown to each other and have a high degree of trust in one another. Partof this trust relies on the client refraining from the service throughoverusing finite server side capabilities. As the model is taken upfurther in more open programming environments in the Internet forinstance it becomes even more crucial to protect server based computingresources through intelligently applied measures.

[0004] The overuse of these capabilities can comprise simple congestiondifficulties but can extend to malicious causes such as denial ofservice attacks. Existing solutions include over provision of front endservers and/or forced disconnection of overuse clients. However thisapproach is very costly both in hardware and software resources andprovides only abrupt reduction in incoming traffic. Agreements withusers can be enforced but often only after the event and through thecourts. Alternatively, certain server systems enable the service tonotify the clients of service outages or congestion. However this isonce again reactive and relies firstly on client recognition andsecondly client reaction, neither of which can be guaranteed.

[0005] One known example of a client server system is shown in FIG. 1.FIG. 1 shows a system including an ideal client 10 and real client 30communicating with a server 12. An application 14 makes a method call toservices 16 running on the server 12 through a distributed computingstub 18. The stub 18 is used to make the service 16 appear local to theapplication 14. Calls including to methods, functions and parameters arepassed into the stub 18 and are marshalled and then serialized such thatthey may be conveyed to the server 12 using a client protocol stack 20.At the server end this data is pulled off the wire by the serverprotocol stack 22 and is then de-serialized and unmarshalled back via adistributed computing skeleton 26 into a method or function call that ispassed to the service 16. The service 16 will perform actions and maycall upon other services running operating backend systems 24. Returnvalues from the service 16 are similarly processed and sent back to thecalling stub 18 and then on to the application 14. In, for example, aJava RMI-based distributed computing system the client applicationaccesses a service capability stub by doing a “lookup” to download theservice capability stub to the client system. The stub provides all themarshalling and un-marshalling capabilities to communicate method callsto the server capability. The client application 14 then calls a givenmethod on the stub 18, this method is then marshalled into a messagethat is transmitted to the server 12 which un-marshals the message backinto the method call which is applied to the server capability object.This object performs tasks and then returns a value through the stubback to the calling client application 14.

[0006] A problem with this design is that when applications operatenormally or obey a Service Level Agreement (SLA), then the calls from asingle client or in a more realistic situation multiple clients 30 willnot exceed the capability of the server 12. In most enterprises theproblem is managed by careful construction and deployment of clientapplications 12 combined with over-provisioned server capacity. Althoughclustering and the use of special clustering stubs can distribute theload over multiple servers, it does not overcome the basic problem ofclient demand outstripping server capacity. When demand does outstripcapacity the server may become impossibly slow, gives rise to failedtransactions and dropped connections and eventually the service andserver may die completely. In most cases it will be the peak trafficdemand that will knock out the server rather than the average traffic.

[0007] The invention is set out in the appended claims.

[0008] Various advantages arise from the invention. Firstly use of thecontrol intermediary allows controls to be applied in real-time to theservice rather than relying on agreements that may be breached.Controlling the service requests using information supplied by theserver will result in more efficient usage of server resources and givethe application programmer interface (API) operator better control ofload on the service. Pre-emptive load control measures can be applied toclients as for instance before a busy period, allowing the API operatorto better manage service levels for the service clients. As a result, ifan instance of the network platform becomes too busy or a servicebecomes unavailable, the client can be rerouted to another instance ofthe platform. Because a transparent initialisation sequence is providedthird party applications will be simpler to implement and there is lessreliance on the third party application developer to factor inresponsible service request control mechanisms. Accordingly servicelevel agreement (SLA) provision is provided in client server systems.Polling of the server by the request manager provides a heartbeatmechanism for both client and server health. In addition the systemallows individual denial of service attacks to be identified and dealtwith before firewall and packet filter mechanisms are applied.

[0009] Embodiments of the invention will now be described, by way ofexample, with reference to the drawings of which:

[0010]FIG. 1 shows a client server system in a known arrangement;

[0011]FIG. 2 shows a client server system according to the invention;

[0012]FIG. 3 shows a client server system according to a furtherembodiment of the invention;

[0013]FIG. 4 shows a more detailed client server model according to theinvention;

[0014]FIG. 5 is a flow diagram of initialisation of the client serversystem according to the invention;

[0015]FIG. 6 is a flow diagram of initialisation steps according toanother embodiment of the invention;

[0016]FIG. 7 shows an implementation of the invention using SOAP and aproxy; and

[0017]FIG. 8 shows a preferred implementation of the invention.

[0018] In overview, the solution that is offered by this invention is todelay and effectively queue up method calls on the client such thattraffic sent to the server is smoothed out. The invention is applicableto any appropriate distributed application but is discussed below withregard to Java systems. In particular, referring to FIG. 2, a service 16on a server 12 has one or more methods which are called by the clientapplication 14 via a distributed computing stub 18 at the client 10comprising a client interface for a class of objects. On the server sidethe distributed computing skeleton 26 routes method calls to the objectimplementation at the server 16.

[0019] According to the embodiment a client is effectively allowed acalling rate of say X method calls per minute/hour/day as required, thethread calling the server 12 goes into the stub 18, but beforemarshalling begins the thread calls intercept on an Integrity ManagementClient (IMC) 32. The IMC 32 can look at the method name, caller, objectname etc and decide to hold back the thread of execution by waiting fora predetermined time, termed “throttling back”. Once this wait iscomplete, the thread is released to continue with the invocation of theservice on the server. In the embodiment shown in FIG. 2 the delayperiod is generated using static information local to the client.

[0020] In the embodiment shown in FIG. 3 the server 12 sends throttleback information to the IMC 32 via a periodic poller client 34. Thepoller client 34 calls “get value” to an Integrity Manager Server (IMS)36 on the server 12 that returns throttleback settings and otherinformation to do with service availability, expected shutdown timesetc. This polling action is termed a “heart beat”. The. IMS can takeinformation 38 from the skeleton 26, service 16 load, user load, server12 infrastructure and other system load information to calculatethrottleback settings according to a predetermined algorithm, or canobtain a direct throttleback delay value from the polled information.The system is such that individual services 16 can be throttled backwhilst others run free or general throttleback can be applied to allservices.

[0021] In this preferred version the delay period of the method call isdynamic generated using static information local to the client anddynamic information available to the server. The periodic polling rateof the client can itself be updated dynamically such that it does notflood the IMSS 36 with unnecessary requests. Client and the server canalso use the polling mechanism to check that each other are alive. TheIMSS can be installed on the same server as the service or any otherdepending on the demands of the installation.

[0022] A second implementation of the invention is to offer SLAmanagement that allows differential services to application developersbased on the level of service. In that embodiment different users can begiven different service levels. This is achieved through extending theIMS generation of calling rate values dependent upon user Id. When theperoidic poller connects to the IMS, the IMS can get the ID of the userfrom the server context information. Where this information does notexist, a user Id parameter can be added in the heartbeat message fromthe IMSC to the IMS so that user may be identified. SLA management mayallow “User A” a method call rate of 1 call per 300 ms, whilst “User B”is allowed a method call rate of 1 call per 150 ms. Safe guards areemployed within the IMS to ensure that users do not connect more thanone client to the server or if they do the method call rates calculatedby the IMS are set accordingly.

[0023] Turning now to a more detailed description with reference to FIG.4, the system is implemented by using the Java 2 Enterprise Edition(J2EE) based client server system but could equally be applied to .NET,CORBA, DCOM, SOAP, Parlay and JAIN technologies as discussed in moredetail below. The skilled person will be familiar with these systems andassociated terms such as Enterprise Java Bean (EJB) which is not,therefore, described in detail below.

[0024] A third party client application 52 runs on a host remote to theserver 12 that provides the service capabilities (single or multipleobject components running on the server) that the client needs. TheClient Application 52 can be any appropriate application written by theuser. The client accesses these service capabilities throughauthentication and access control mechanisms operated by the serviceprovider. As part of the service level agreement that exists between theclient business and the service provider is that a Software DevelopmentKit (SDK) that contains special communication capabilities must bedownloaded and installed on the client system. The client sidecomponents are installed through the Software Development Kit in theform or a downloadable zip or tar file. These aspects will be familiarto the skilled reader and are therefore not discussed further here.However, the special client side components shown in FIG. 4 allow theservice provider to be polled for throttleback settings. The clientstubs 50 interact with the client side components to cut back or delayinvocations of methods on the various service capabilities running onthe server 12 as mentioned above.

[0025] The Service Capability Stub 50 is a doctored Remote MethodInvocation (RMI) stub which is a client side object that acts as a proxyto marshal and un-marshal values that are sent to and received from theserver 12. RMI stubs are classes that are generated by the use of toolssuch as Javasoft's RMIC when building server side components.

[0026] The Integrity Manager Client's 32 primary job is to request andstore throttleback settings from the Integrity Manager Server 36 in arepository. A stub controller 54 is responsible for managing thethrottling back of methods for the various service capabilities. Itaccesses the throttleback settings from the IMC 32. A Heartbeat thread(MBT) 56 polls the IMC periodically to call “heartbeat” information,discussed in more detail below, from an Integrity Manager in the server12. When a method is called on the service capability, it checks theappropriate stub controller. If necessary the stub controller will delayor reject the thread before accessing the underlying service capability.In the following discussion references to IMS, IMSS and server side IMall refer to the server side integrity manager, and references to IMC,IMSC refer to the client side integrity manager.

[0027] Turning to the server side, a Service Capability Home 58represents a manager class for the service capability which is part ofthe J2EE specification allowing access to further relevant softwarecomponents. In one embodiment (not shown) the home 58 could itself bethrottled back as it is a remote object.

[0028] The Service Capability stored on a service capability server 60represents an individual service that the customer uses. In theexemplary embodiment it has a method “aMethod”. Associated with theservice capability is the client side stub 50 that is downloadedautomatically when a client does lookup of the object or a reference ispassed back to the client through some other mechanism. This automaticdownload ensures that throttleback is installed prior to access beingavailable to the service.

[0029] The Integrity Manager (IM) Server Side 62 represents a managerthat is responsible for calculating throttleback information toIntegrity Manager Clients. In this case it is shown as an EnterpriseJava Bean (EJB) and thus includes a home interface 64 for accessing it,all hosted on the IMS 36.

[0030] The server side components are operated by the service providerand are made accessible through a Java RMI interface/Enterprise JavaBean programming model. For simplicity of illustration this inventiondoes not reveal the remote interfaces, remote objects, stubs, skeletons,authentication and access control mechanisms that are standard withapplication servers unless they feature specifically in the invention.

[0031] The first stage of use of the invention is initialization. Asimple version of initialization of the client-server is illustrated inFIGS. 2, 4 and the flow chart of FIG. 5. This describes the scenariowhere an example application 14 attempts to access a service 16capability on the server 12. Before the example application 14 can dothis the client application must initialize special client sidecomponents. Initialization is mandatory for all clients, failure to doso will result in future calls to the server being blocked.

[0032] Initialization is performed as follows. At step 80 the clientapplication 14 attempts to contact the local Integrity Manager Client32. If one is not already running, at step 82 the application 14 will benotified by a null return and the application must then start theinitialization process at step 84 by calling an appropriate routine. Thenew IMC 32, creates a new context allowing a directory lookup at step 86for components running on the server 12 to get the server initialcontext onto the directory. The IMC 32 then performs a lookup for theIntegrity Manager Home (IMH) object 64 on the server 12 (step 88). Forauthentication purposes, the user may need to include principal andcredential information to create the context. The IMC 32 then creates aserver object (step 90) through accessing the IMH 64 with an appropriatemethod. The IMC 32 will now have a reference to the Integrity Manager(IM) server 36 instance for future reference. At this point 92 the IMC32 will then start the Heartbeat Thread (HBT) 56 passing its self asparameter. The client application is ow free to make calls on the server(step 94). Once the HBT 56 has been initialized it will runcontinuously, polling the IMC until the client application is stopped.

[0033] In a preferred transparent version of the initialisation stepsshown in FIG. 6 the client 10 does not have to change the programmingmodel to initialize the system and from a service provider'sperspective, the system is foolproof such that the client side classeswill be started every time the client attempts to use the servicecapabilities (step 100) running on the server 12. An example set ofinformation flows that have been implemented for Java 2 EnterpriseEdition clients to transparently start the server side classes exploitsthe InitialContextFactory (ICF) capability 51 of J2EE using anexplicitly defined InitialContextFactory aspect 53 at step 104 thatwould be referenced in the creation of an InitialContext (step 102). Atstep 106 the ICF aspect merely starts the IMC 32 if not alreadyimplemented (step 108), does a lookup for the IM home, creates a IMserver then starts a new heart beat thread as described above. It thencalls the standard J2EE ICF implementation (step 110), which could besupplied with a SilverStream, iPlanet or BEA Weblogic application serveror any other appropriate server.

[0034] In system terms, the client application calls the InitialContext55 (comprising a directory for lookup of applications) with the ICFaspect 53 as a parameter. The ICF aspect 53 can check whether the IMC 32is running, and if not it can start the IMC 32 with the appropriatemethod. The IMC 32 then accesses the InitialContext 55, again this timeusing the installed application server's ICF (i.e. the serverimplementation of the InitialContext access). Finally the same threadcalls an InitialContext on the installed application servers ICF andpasses the result at step 114 back to the client.

[0035] Once the system is initialised and running polling of theintegrity manager server is performed to ensure that the clientinstallation is kept up to date with the throttle back settings of theserver. Referring once again to FIG. 4, once the IMC 32 has beeninitialized, the HBT 56 will poll the IM server object 36 with theappropriate method. This method not only notifies the server 12 that theclient installation 10 is still running, but allows the IMC 32 to accessthrottleback settings and other server settings. The settings arereturned the IMC 32 in the method call and are stored as a java.lang.Properties object of name value pairs. The settings also contain a HBTpoll period setting that the HBT 56 can pick up and thus update and setits polling rate. If authentication is in place, the IM 62 caninterrogate the calling thread to identify the calling application. Inthis way the server 12 can calculate specialized settings for thatparticular application, providing different service levels for differentusers.

[0036] As discussed above controlling of calling rates is achieved byintercepting the method call thread in the stub and if necessarydelaying the thread for a pre-determined time before actuallytransmitting the message to the server dependent on delay data that canbe static or dynamic.

[0037] As before, when a service is invoked the client application 14accesses the service capability stub 50 by doing a lookup from the J2EEInitial Context. The lookup then downloads the service capability stub50 to the client system 10. The stub 50 ensures that, when methods arecalled on it, it can delay the threads on the client installation 10without impacting on the server 12. When a method call is made, the stubcalls the Integrity Manager Stub Controller (IMSC) 54 with the methodname and stub class type. The IMSC 54 then calculates the necessarythread delay for a method. It then makes the thread sleep for the threaddelay period. The IMSC 54 can get the most up to date information onthrottleback settings from the IMC 32.

[0038] The invention supports various methods of constraining the clientwhen accessing the server 12 or service 16. IMS 36 sets the method callrates that are returned to the IMSC.

[0039] For example throttleback can be imposed on all methods of aspecific service (X) 16. This is done by the IMS 36 setting theSERVICE_X_CALL_RATE value to a given rate or period value and the IMSC32 ensuring all calls are delayed according to the rate. Alternativelythrottleback can be imposed on a specific method (Y) of a service (X)16. This is done by the IMS 36 setting the SERVICE_X_METHOD_Y_CALL_RATEvalue and the IMSC 32 ensuring all calls are delayed according to therate or throttleback can be imposed on all methods on a server (W) 12irrespective of which service 16 within the server they are on. This isdone by the IMS 36 setting the SERVER_W_METHOD_CALL_RATE value and theIMSC 32 ensuring all calls are delayed according to the rate.

[0040] Further throttleback can be imposed on all methods of aninstallation where there may be more than one server 16. This is done bythe IMS 36 setting the METHOD_CALL_RATE value and the IMSC 32 ensuringall calls are delayed according to the rate.

[0041] By a combination of all of the above, throttleback can be imposedon all methods of an installation where there may be more than oneserver. This is done by the IMS 36 setting theSERVER_W_SERVICE_X_METHOD_Y_CALL_RATE value and the IMSC 32 ensuringthat calls are delayed according to the rate. For example an IMS ratesetting of “SERVER_fore1.acme.com:1234_SERVICE_mail_METHOD_send_CALL_RATE=6000” will result in the client calling the send ( ) method on themail service that runs on the server fore1.acme.com:1234 once every 6000milliseconds.

[0042] Table 1 shows examples of the return properties received by theIMC when polling the IM. TABLE 1 Name Description HEARTBEAT_POLL_PERIODDelay between future heartbeats from the client in seconds.METHOD_CALL_RATE General delay in call rates for all non- specifiedservice capabilities and methods in milliseconds. HEARTBEAT_POLL_TIMECurrent system time in milliseconds CLIENT_VERSION Client version forcompatibility. SERVICE_ULS1_METHOD_ Specific call rate for ULS1 serviceM1_CALL _RATE for method #1 in milliseconds. SERVICE_ULS1_METHOD_Specific call rate for ULS1 service M2_CALL_RATE for method #2 inmilliseconds.

[0043] The waiting algorithm can be set on the client 10 such thatconditional clauses can be applied to the delay rates. The waitingalgorithm used in the invention is such that client IMSC 32 calculatesthe waiting period based on time since last method was sent. This meansif the calling rate of the application 14 is 1 call per 10000 ms and theMETHOD_CALL_RATE as set by the IMS is 5000 ms then methods will not bedelayed. However, if the calling rate of the application is 1 call per5000 ms and the METHOD_CALL_RATE as set by the IMS is 10000 ms then themethod will be delayed by 5000 ms. This can be implemented using anappropriate conditional clause.

[0044] Although the implementation developed for this invention uses await time derived directly from the rate value there is the ability forthe IMS 36 to set a METHOD_DELAY_ALGORITHM that could relate to client10 based mechanism such as a random “backoff” wait period.

[0045] In the case of a service capability becoming completelyunavailable, or requiring no further calls, the IM 62 can be programmedto send complete throttleback settings to the IMC 32. The stub 50 willthen intercept, rather than delay the thread as before, by setting ajava.rmi.RemoteException with “COMPLETE_THROTTLEBACK” in the messagebody of the exception. In addition to the IM 62 sending completethrottleback settings it may also include the URL (Uniform ResourceLocator) of an alternative server which can provide a replacementservice capability. This allows the client to be rerouted to anotherinstance of the platform.

[0046] Similarly, in the event that the server itself becomesunavailable, the IMC 32 is arranged to time out. At this point, the IMCwill set all throttleback settings to blocked, and will immediatelyblock all further method calls to components on the server 12. The IMCmay be pre-programmed with (or alternatively it may have been notifiedperiodically by the IMS of) the URLs of other available servers. Assuch, the application 52 can request of the IMC an alternative server touse. If full throttle back is applied to the client and traffic is stillsent to the network server in breach of the request, then server sidepacket filters, server components and firewalls may be instructed toremove offending traffic.

[0047] The skilled reader will recognise that the invention is describedwith respect to Java systems but would be applicable to otherdistributed applications.

[0048] For example Common Object Request Broker Architecture (CORBA)implementations are built as follows. The IMS and services are developedin any language and installed on the server. The Application ProgrammeInterface (API) allowing the programmer to access the module of thesecomponents is described in an Interface Definition Language (IDL) file.An IDL compiler (i.e. Javasofts idlj tool) takes the IDL file andgenerates interface classes, client stubs, server skeletons (baseclasses) source code and so forth. The implementer edits the client stubsource code such that an intercept call is made out to the IMSC when amethod was called. All these components are compiled into bytecodes orbinaries dependant upon the target systems. The IMSC can be implementedin a language that it compatible with the client. The clientinstallation consists of the special client stubs, interface classes andIMSC components. The client application would then be written that wouldcommunicate with the stubs to access the service and IMS.

[0049] Remote Method Invocation (RMI) implementation is very similar tothe CORBA example. The API is defined as a remote Java interface, aprogram such as RMI stub compiler (RMIC) is used to generate the stubsand skeletons source code. The stubs are then altered to make thespecific call to an intercept method on the IMSC. Again these componentsare compiled into bytecodes. The client installation consists of theinterface classes and IMSC components. The client application is thenwritten to communicate with the stubs to access the service and IMS. Thespecial stub is installed on the server. This special stub is downloadedwhen a call is made to the service running on the server. The clientapplication is then written that communicates with the stubs to accessthe service and IMS as discussed above.

[0050] Accordingly, through Java RMI, stubs can be downloaded on a perusage basis such that they can be used to control access to theunderlying service capability running on the server. In non Java RMIsystems, the stubs would be downloaded one time as part of the ServiceDeveloper Kit (SDK) comprising development and service access capabilitycontrol software on the client SLA agreement which would work in thesame ways as the Java RMI stub in intercepting message calls.

[0051] Simple Object Access Protocol (SOAP) implementation is built asfollows. SOAP is built around packaging method calls into XML documentsand sending them normally using HTTP-POST messages to the server.Language dependent stubs operate in a similar manner to the distributedcomputing stubs 18 of FIG. 2 and enable the application developer toavoid all the issues of hand coding serialization of method calls. Thelanguage dependent stub intercepts a method call before the method callis serialized into XML elements and posted via HTTP to the server. Thelanguage dependent stubs are generated when the service is developed.Server companies such as BEA offer a tool that generates the stub and asbefore these can be altered by the implementer such that interceptionsare made when a method is called.

[0052] Referring to FIG. 7, where in the SOAP implementation a pure HTTPinterface is offered via HTTP Protocol stack 120 to the clientapplication 14, the proxy 122 version can be used. This will allow rawmethod calls posted to the server to be intercepted by a proxy 124carrying HTTP Protocol stack 126. Although the proxy could “wait” amessage then forward it on this in many cases could lead to congestionon the proxy which could again suffer at the hands of malicious or badlywritten applications. Here, throttling back can be by notification backto the client application when they are sending too many method calls.If the application does not reduce the calling rate then method call“POST” messages can be dropped by the proxy thus protecting the server.This proxy approach can be applied equally in other implementations asappropriate.

[0053] This invention can further be applied in Java APIs for IntegratedNetworks (JAIN) by developing special client side libraries as part ofAPIs such as JAIN™SIP, JAIN™ Call Control, JAIN™MAP and JAIN™ SPAMobility APIs. Key methods on server objects would be intercepted on theclient side API.

[0054] An example of one implementation is shown in FIG. 8 where aclient machine 130 which can be a Windows TM NT machine or any otherappropriate PC communicates over a local area network (LAN) 132 with aserver machine 134 which can be a Sun Server using Solaris or any otherappropriate system such as a Unix/POSIX or Linux system. Where theclient 130 represents an untrusted third party a user location requestis sent to the service provider domain (server 134) at differentintervals. Additional SDK classes 135 are installed on the client side130 and a User Location Service (ULS) stub 136 is shown on the client130 having been downloaded at run time. All client side codes run withina JAVA 1.3 virtual machine 138 which runs the ULS client application.

[0055] At the server 134 the user location 140, stub code 142 andintegrity manager 144 are installed and running on a J2EE BEA weblogicserver. Communication between the client 130 and server 134 uses RMIover BEA'S T3 protocol although other appropriate protocols can ofcourse be used. The integrity manager 144 at the server is linked toJAVA server pages (dynamically generated html application) 146 allowingthrottle back settings to be set on the fly by the server provider froma web browser 148.

[0056] In operation the application 137 accesses the server 134 usingthe Initial Context Factory aspect which starts up the client sideclasses 135. The server object 140 is accessed and the ULS stub 136 isdownloaded to the client. The application then communicates with the ULSserver via the stub 136. Each call to the stub determines whether adelay should be applied to the thread of execution. At the same time theIMC with the help of the heartbeat thread periodically downloadsthrottle back settings. Through control of the Java server pages (JSP)within the web browser which contain dynamically generated html contentit is possible to set the duration between allowed server method callssuch that client side classes 135 (ie client hosted implementationsoftware) begin to throttle back the client 130. At this point clientthreads begin to be stopped for a predetermined period before they areallowed to continue to make the call to the server object 140.

[0057] It will be recognised that the invention can be implemented onany appropriate computer system or network and using any appropriateplatform or protocol without departing from the inventive concept. Inparticular although the description is principally based on client andserver provided across the Internet, this invention could be used withinmulti-tiered application servers i.e. between Web components such asJava Server Pages, Active Server Pages, Servlets and server componentssuch as objects or Enterprise Java Beans. Likewise the mechanism couldbe implemented between one server component and another or betweenserver components and resources such as database connection pools.

1. A method of controlling service requests to a first module acting asa server module from a second module acting as a client module, themethod comprising: at the second module, a control intermediaryintercepting and controlling transmission of service requests to thefirst module.
 2. A method according to claim 1, the step of controllingtransmission of service requests comprising delaying and/or inhibitingtransmission of service requests to the first module.
 3. A methodaccording to claim 1, the intermediary controlling transmission ofservice requests in accordance with control information received fromthe first module.
 4. A method according to claim 3, in which the controlinformation received from the first module is available locally to theintermediary from a store of the second module.
 5. A method according toclaim 3, in which service requests relate to one or more of a pluralityof service capabilities provided by the first module, in which thetransmission of a service request is controlled depending upon theservice capability or capabilities to which the request relates.
 6. Amethod according to claim 3, further comprising the step of: the firstmodule receiving from the second module in addition to the controlinformation an address of a third module of the computer system, saidthird module being suitable for providing a service capability in theevent that the control intermediary inhibits transmission of servicerequests for the same service capability.
 7. A method according to claim3, further comprising the step of: the control intermediary periodicallypolling the first module to obtain updated control information.
 8. Amethod according to claim 7, the control information comprising apolling rate for the intermediary.
 9. A method according to claim 7, thestep of polling comprising providing an identification of the secondmodule and/or user, the method further comprising: at the first module,selecting control information to send to the second module based on theidentification of the second module and/or user.
 10. A method accordingto claim 1, further comprising: at the first module, identifying anunacceptable service request from a second module if the first modulelacks an indication that a control intermediary is operating at thesecond module.
 11. A method according to claim 10, further comprising:at the first module, upon receiving an unacceptable service request thefirst module transmitting to the second module instructions forimplementing a control intermediary at the second module.
 12. A methodaccording to claim 1, further comprising: at the first module, uponreceiving a first service request for a service capability transmittingto the second module instructions for implementing a controlintermediary at the second module.
 13. A computer system comprising afirst module acting as a server module and a second module acting as aclient module arranged to send service requests to the first module, thesecond module comprising a control intermediary arranged to interceptand control transmission of service requests to the first module.
 14. Asystem according to claim 13, in which: the control intermediary isarranged to control transmission of service requests by delaying and/orinhibiting transmission of the service requests.
 15. A system accordingto claim 13, in which: the control intermediary is arranged to controltransmission of service requests in accordance with control informationreceived from the first module.
 16. A system according to claim 15, inwhich: the intermediary is arranged to access the control informationlocally from a store of the second module.
 17. A system according toclaim 15, in which service requests relate to one or more of a pluralityof service capabilities provided by the first module, and in which: theintermediary is arranged to control transmission of a service requestdepending upon the service capability or capabilities to which therequest relates.
 18. A system according to claim 15, in which: the firstmodule is arranged to send to the second module an address of a thirdmodule of the computer system in addition to the control information,said third module being suitable for providing a service capability inthe event that the control intermediary inhibits transmission of servicerequests for the same service capability.
 19. A system according toclaim 15 in which: the control intermediary is arranged to periodicallypoll the first module to obtain updated control information; and thefirst module is arranged to send updated control information to thesecond module upon receipt of polling by the second module.
 20. A systemaccording to claim 19, the control information comprising a polling ratefor the intermediary.
 21. A system according to claim 19, in which: thecontrol intermediary is arranged to provide an identification of thesecond module and/or user when polling the first module; and the firstmodule is arranged to select control information to send to the secondmodule based on the identification of the second module and/or user. 22.A system according to claim 13, in which: the first module is arrangedto identify an unacceptable service request from the second module ifthe first module lacks an indication that a control intermediary isoperating at the second module.
 23. A system according to claim 22, inwhich: the first module is arranged to, upon receipt of an unacceptableservice request, transmit to the second module instructions forimplementing a control intermediary at the second module.
 24. A methodaccording to claim 13, in which: the first module is arranged to, uponreceipt of a first service request for a service capability, transmit tothe second module instructions for implementing a control intermediaryat the second module.
 25. A computer arranged to act as a first moduleof the system according to claim
 13. 26. A computer arranged to act as asecond module of the system according to claim
 13. 27. A storage mediumcarrying computer readable code representing instructions for causingone or more computers to perform the method according to claim 1 whenthe instructions are executed by one or more computers.
 28. A computerdata signal embodied in a carrier wave and representing instructions forcausing one or more computers to perform the method according to claim 1when the instructions are executed by one or more computers: